home *** CD-ROM | disk | FTP | other *** search
- Path: pangea.Stanford.EDU!karish
- From: karish@pangea.Stanford.EDU (Chuck Karish)
- Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
- Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
- Date: 15 Apr 1996 20:36:38 GMT
- Organization: Mindcraft, Inc.
- Message-ID: <4kuc0m$398@nntp.Stanford.EDU>
- References: <JSA.96Feb16135027@organon.com> <dewar.829399701@schonberg> <4kpceq$e4b@solutions.solon.com> <dewar.829446681@schonberg>
- NNTP-Posting-Host: pangea.stanford.edu
-
- In article <dewar.829446681@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
- >On the other hand, that same book says
- >that unlink is implemented in all systems, so clearly at least for the
- >moment unlink is safer to use if you are aiming at maximum portability.
- >Rememerb that gcc is targeted to more than 300 different C library
- >environments, and you want to absolutely minimize conditional stuff.
- >That's what I meant by having a strenuous view of portability. I would
- >rather guess that Peter is pretty Unix oriented, and of course we are
- >trying for a wider scope of portability than Unix!
-
- But unlink() is a UNIX system call that was also implemented in
- many other environments. unlink() on UNIX and POSIX systems is
- only guaranteed to work if the argument is the name of a
- regular file; on many systems, unlink() fails for directories.
-
- The rationale for ANSI C says that remove() was meant to be
- a generalized re-casting of the unlink() functionality, free of
- UNIX filesystem terminology ("link"). Implementations of remove()
- are allowed (but not required!) to do the right thing no matter
- what type of file they're used on.
- --
-
- Chuck Karish karish@mindcraft.com
- (415) 323-9000 x117 karish@pangea.stanford.edu
-